home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1988 / Aug-Sep 88 / Re- Response to ?'s ⁄ 10.21.88 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.1 KB  |  48 lines  |  [TEXT/GEOL]
  1. Item    9504208                         21-Oct-88        14:42
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     D1713                           Attachmate, Dev, John Bartleson
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    re Response to Questions
  10.  
  11. MacApp 1.1 explicitly makes the segments containing the routines
  12. CmdFromMenuItem and BuildAllReserves resident in the procedure InitToolBox.
  13. MacApp 2.0b5 calls LoadResidentSegments, which makes all the segments listed in
  14. any the res! resource resident (as you indicated).  Marking a segment as
  15. resident is done with a call to SetResidentSegment.  All this does is cause
  16. UnloadAllSegments to skip the segment.  (The Segment Loader has no notion of a
  17. resident segment; this is a MacApp concept.)
  18.  
  19. The question about having enough memory to load a segment is important.  The
  20. Segment Loader will bomb if it can't load a segment (mainly because there is
  21. nothing else for it to do).
  22.  
  23. You prevent this from happening with the seg! and mem! resources.  You indicate
  24. to MacApp the amount of memory to reserve for code segments and similar
  25. resources.  MacApp will maintain keep this memory in reserve and only release
  26. it when needed to load a code segment.  Normally, you figure out the maximum
  27. amount of code loaded at one time, and list those segment names in the seg!
  28. resource.  The mem! resource allows you to add a little extra slop (for things
  29. such as window defprocs, packages, etc.)
  30.  
  31. There is no (clean) way to get the address of a method.  Creating a regular
  32. procedure that calls the method is the best approach.  The problem is that the
  33. code that gets called depends on the object receiving the message and the
  34. message itself, and in general will be different for different receivers.
  35.  
  36. If you want to call a method from an I/O completion routine, you have to beware
  37. because objects are handles, and you cannot depend on unlocked handles being
  38. consistent at interrupt level.  You should, however, be able to lock the object
  39. and send messages to that object at interrupt level.  (All the other
  40. restrictions on interrupt level code still apply as well.)
  41.  
  42. Larry Rosenstein
  43.  
  44.  
  45.  
  46.  
  47.  
  48.